Much of the following background on relational databases is taken from Introduction to Relational Databases-Part 1: Theoretical Foundation by Tore Bostrup, at http://www.15seconds.com/Issue/020522.htm?voteresult=5. An important aspect of today's world is information: obtaining it; organizing it; storing it; accessing it, etc. Indeed, much of the world's computing power is dedicated to maintaining and using information, typically stored in databases. All kinds of data, from electronic mail and contact information to financial data, records of sales, performance data of processing units are stored in some form of a database. Realizing the importance of meaningful storage of data, in 1970 Dr. E. F. Codd, developed the relational model of databases based on how users perceive data and a mathematical theory of relations. The relational model represents data as logical entities in which each logical entity represents some real-world person, place, thing, or event about which information is collected. A relational database is a set of tables derived from logical entities and manipulated in accordance with the relational model of data. The basic objects in the database are tables, columns, views, indexes, constraints (relationships), and triggers. Articles by Dr. E. F. Codd throughout the 1970s and 80s such as TWELVE RULES FORRELATIONAL DATABASES and IS YOUR DBMS REALLY RELATIONAL? published in COMPUTERWORLD on Oct. 14, 1985 and DOES YOUR DBMS RUN BY THE RULES? published in COMPUTERWORLD on Oct. 21, 1985 are still referenced for implementation of relational databases. The twelve rules now number 333 rules and are published in The Relational Model for Database Management, Version 2 (Addison-Wesley, 1990).
The problem with data is that it changes. Not only do the values change but also a datum's structure and use, especially when kept for extended periods of time. Even for public records maintained in perpetuity, there may be changes in what data are captured and recorded and how. Normalization avoids problems resulting from duplication of data values and modification of structure and content; normalization ensures data consistency and stability, minimizes data redundancy, ensures consistent updatability and maintainability of the data, and avoids “update and delete” anomalies that result in ambiguous data or inconsistent results.
The normalization process is based on collecting an exhaustive list of all data to be maintained in the database and starting the design with a few “superset” tables. For normalization, the first normal form removes repeating or multivalued attributes to another child entity; basically, the first normal form ensures that the data is represented as a proper table, i.e., the formal name for “table” is “relation.” While key to the relational principles, this is somewhat a motherhood statement. In addition, there are six properties of a relational table: (1) all entries in columns are single-valued; (2) entries in the same column are of the same kind; (3) each row is unique; (4) the sequence of columns is insignificant; (5) the sequence of rows is insignificant; and (6) each column has a unique name. The most common sins against the first normal form are the lack of a primary key and the use of “repeating columns” wherein multiple values of the same type are stored in multiple columns. The second normal form removes attributes that are not dependent on the whole primary key to make sure that each column is defined in the correct table, or more formally that each attribute is kept with the entity that it describes. The third normal form removes attributes that depend on other so that data that can either be derived from other columns or belong in another table should not be stored in the database. Some database designers may apply additional levels of normalization.
FIG. 1A is a representation of a database for a computer central processing unit's performance. Databases are traditionally configured as a tables with rows and columns. A primary key is one or more columns whose values uniquely identify a row in a table. Examples of primary keys in FIG. 1A include the System Identifier, the Date, the Hour. A key uniquely identifies each row in a table. A domain is the set of permissible values for an attribute. By enforcing key and domain restrictions, the database is assured of being freed from modification anomalies. A candidate key is one or more columns whose values could be used to uniquely identify a row in a table. The primary key is chosen among a table's candidate keys.
The background discussion will now shift to describing a binary large object (BLOB). A BLOB is a collection of binary data stored as a single entity in a database management system. BLOBs are typically images, audio or other multimedia object, though binary code is sometimes stored as a BLOB. Database support for BLOBs is not universal. A BLOB has no structure which can be interpreted by the database management system; it is known only by its size and location. Most mainframe-style database engines, with the exception of some recent object-relational engines, only store BLOB data and do not attempt to manipulate it in any way. Once a BLOB is stored on a remote database server, all identifying features that associate it with a particular application are lost. Therefore, any association between a BLOB's contents and the application used to create and maintain it must be maintained separately. For example, most video recordings are stored as AVI files, and opened by default with the web server's video program. Thus, to display a BLOB, the following sequence of events takes place. The web server extracts the BLOB's bytes from the database server and creates a temporary file in a folder on the web server. This file is assigned the appropriate extension, and a hyperlink to the file is created on the web page that is generated for the user. Typically, there have been no means for an end-user to upload or edit a BLOB to or in a database through the web client. Instead, uploading is done through the MS-access administrator front end. Similarly, these actions were typically performed by an administrator front-end.
Traditionally, data in a database has been stored in individual rows of the database, and because of this there is a need to store multiple rows of clustered data in a more meaningful way, especially when the data is clustered, i.e., when the data is statistically significant and particularly useful when accessed and analyzed all at once. There is a further need to simplify and speed access to clustered data comprising multiple rows of data in a database. These needs and other that will become apparent are satisfied by the invention as stated below: